1. Field of Invention
The present invention relates generally to energy usage profiling, and more particularly, to the energy-based sampling of computing resources in order to profile energy consumption.
2. Background of the Invention
Limited battery life is a well-known problem with portable computers. Since batteries can store only a limited amount of engergy, energy is a critical resource for portable computers. In order to optimize software for reduced energy consumption and extended battery life, it is important to understand how energy consumption is affected by program behavior. System and software designers need to understand how program execution affects energy consumption. Ideally, these designers would like to attribute energy consumption to specific software components such as applications, processes, or even individual functions and operations.
Such detailed information would facilitate manual or automated identification of the code sequences that account for a significant portion of the overall energy consumption. It also would facilitate manual or automatic optimizations to be applied to these sequences with the aim of reducing overall energy consumption and extending battery life. Some optimizations may involve replacing particular code sequences with more energy-efficient alternatives. Other optimizations may also involve algorithmic changes. For example, to detect the occurrence of asynchronous events, it is often more energy efficient to use interrupts than to busy wait. However, because it is easier to write a program to use busy waiting, designers may wish to only use interrupts where doing so would save a noteworthy amount of energy. The method in which applications interact can also incur an energy cost. For example, a poorly designed synchronization mechanism may result in applications that, while accessing a shared resource, spend a lot of time unnecessarily waiting and hence waste energy. Finally, the design of the operating system can also impact the energy consumed by both itself and applications running on top of it. For example, in a multitasking operating system, a poorly chosen timeslice interval may cause unnecessary context switches or cache flushes.
Statistical sampling is a well-known technique for monitoring the performance of software systems. Sampling-based systems, such as Compaq""s(trademark) Continuous Profiling Infrastructure (DCPI), statistically estimate the number of events associated with regions of code, such as the number of cycles spent executing a function, or the data cache miss rate of a load instruction. This type of sampling-based system is described further in U.S. Pat. No. 5,796,939, entitled xe2x80x9cHigh Frequency Sampling of Processor Performance Counters,xe2x80x9d issued Aug. 18, 1998, the subject matter of which is herein incorporated by reference in its entirety. To support such sampling profilers, many processors contain specialized hardware to count events and generate an interrupt after a specified number of events have occurred. For example, the Compaq(trademark) Alpha 21164 microprocessor can count dozens of events, including processor cycles, fetched or executed instructions, data or instruction cache misses, and translation lookaside buffer (TLB) misses.
Assuming that interrupts are delivered promptly, the number of event-based samples associated with a program location (i.e., the interrupted program counter address, or PC) will be proportional to the total number of events that occurred at that location. For example, in DCPI profiles, instructions that take longer to execute will accumulate proportionally more xe2x80x9ccyclesxe2x80x9d events, and instructions that miss more often in the instruction cache will accumulate proportionally more xe2x80x9cimissxe2x80x9d events.
Although statistical sampling of program structures is well known, these statistical sampling techniques do not provide a mechanism by which the energy consumed by a program may be mapped to specific software components. For the reasons noted above, it would be desirable to extend the functionality provided by DCPI and other monitoring systems to the domain of energy profiling.
A prior art approach to mapping energy consumption to software components is given by Jason Flinn and M. Satyanarayanan in, xe2x80x9cPowerScope: A Tool for Profiling the Energy Usage of Mobile Applicationsxe2x80x9d, Proceedings of the 2nd IEEE Workshop on Mobile Computing Systems and Applications, New Orleans, La., Feb. 25-26, 1999 (xe2x80x9cPowerScopexe2x80x9d). PowerScope profiles the power consumed by applications running on a computer system by using an external digital multimeter and a second computer for data collection. To begin profiling, the data collection computer configures the multimeter to generate a trigger at fixed time intervals. Each time the trigger occurs, an interrupt-service request is registered with the computer being profiled. When this computer subsequently services the interrupt, software running on the computer collects a sample containing the current process ID (PID) and program counter address (PC). Before a trigger is generated, however, the multimeter measures and records the amount of electrical current being drawn by the profiled computer, since variations in the supply voltage were found to be small. The instantaneous current reading is then transferred asynchronously to the software running on the data collection computer.
Once profiling has been completed, the current readings and PID/PC samples are processed. PowerScope first estimates the energy consumption during each time interval. The estimate assumes that each instantaneous current reading represents the average amount of current drawn during the corresponding interval. Accordingly, the energy consumed during an interval is estimated as the product of the length of the time interval, the current reading for the interval, and the predetermined and assumed constant value of the supply voltage. Next, PowerScope correlates these estimates with the PID/PC samples.
The PowerScope profiling approach of time-based instantaneous power measurements has several significant disadvantages, including a lack of simplicity, accuracy, and efficiency. The PowerScope system design is cumbersome. For instance, PowerScope requires an external digital multimeter, connected to a second, separate computer system that records energy readings. It would be more practical and less expensive to have a simpler system that could be incorporated into the computer system of interest.
The PowerScope approach also introduces two potential sources of inaccuracy. First, the sampling interval is based on time, and the energy measurements reflect only the instantaneous power usage when samples are taken. PowerScope assumes that the cumulative energy over the interval can be computed as the product of the interval duration and the instantaneous power measurement. However, this assumption is suspect, since application power consumption varies over time, and is not necessarily correlated with time.
The large variation in power consumption over time is illustrated by the power usage graph shown in FIG. 3. This graph plots the power consumed by an Itsy Pocket Computer from Compaq(trademark) as the Linux operating system is booted and several applications are run. The power data in FIG. 3 was obtained by measuring 50 times a second the current supplied to the Itsy and the supply voltage. As shown in FIG. 3, the power consumed fluctuates between approximately 0.2-1.8 watts.
Second, to avoid significant distortion from the power consumption of the interrupt handler that runs on the system being profiled, PowerScope delays the interrupt until after the multimeter has finished making its instantaneous power reading. By so doing, a significant amount of skew is introduced between the meter and the computer being profiled. This skew is sufficient that PowerScope cannot be used to accurately map energy consumption to program structures any smaller than a procedure.
PowerScope records energy measurements and program location samples separately (in fact, on different computers), and the separate sets of data are correlated offline at a later time. This restriction prevents several optimizations, such as the online aggregation of data (e.g., as used in DCPI). In addition, PowerScope is energy-inefficient, since the number of samples taken is proportional to time, and not energy consumption. PowerScope also may significantly perturb the system being monitored. For example, some processors (such as the Intel(copyright) StrongARM SA-1100 used on the Itsy Pocket Computer) support a low-power idle mode that is exited when an interrupt occurs. In this case, each interrupt will bring the processor out of idle mode, thereby needlessly consuming energy. Further, if the sampling rate is sufficiently high that the system does not re-enter the low-power mode before a subsequent sample occurs, the samples so obtained will not reflect the actual energy consumption of the system. These two potential effects are exacerbated by the insensitivity of the sampling rate to the level of power consumption. That is, in spite of the system being in a low-power mode, samples will continue to be acquired at a rate more suited for when the system is consuming a greater amount of power.
Accordingly, there is a need for a system and method for energy usage profiling of computing resources that overcomes the lack of simplicity, accuracy, and efficiency found in the prior art.
The present invention performs energy usage profiling of computing resources using an energy-based interrupt source for sampling. The present invention introduces energy consumption as a new type of event to be monitored by specialized profiling hardware. An energy consumption counter tracks the energy consumed by the computing resources and generates an interrupt after a specific amount of energy has been consumed. Profiling software uses the counter to statistically estimate the amount of energy used by regions of code at various levels of abstraction. Code that uses more energy to execute will accumulate proportionally more samples, producing an energy usage profile that is both detailed and accurate, as desired.
In one embodiment, an energy profiling system comprises an energy counter for measuring energy consumed by a computer system and an energy comparator that generates an interrupt request subject to a determination that the energy counter has reached a predetermined energy threshold. The energy profiling system further includes a sampling driver (software than runs on the computer system of interest) for recording information about a region of computer code in response to receiving the interrupt request. Such information includes the current process ID and the PC address of the instruction currently in execution at the time that the interrupt is serviced. The energy profiling system resets after each interrupt request to resume measuring energy usage.
In another embodiment, an energy-based sampling system comprises a circuit for measuring the energy drawn from a power source and sending a signal when an energy threshold is reached, and a count-down counter coupled to the circuit for receiving the signal and generating an interrupt request when a predetermined number of signals have been received. Thus, this embodiment limits the occurrence of interrupts to a fixed multiple of the energy threshold. The system further includes a processor for receiving the interrupt and suspending the execution of a current application executing on the processor so that the sampling driver may be run.
The features and advantages described in the specification are not all-inclusive, and particularly, many additional features and advantages will be apparent to one of ordinary skill in the art in view of the drawings, specification, and claims hereof. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter.
The foregoing merely summarizes aspects of the invention. The present invention is more completely described with respect to the following drawings and detailed description.